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I.  EXECUTIVE  SUMMARY 


Purpose  of  Study 

The  need  for  precise  and  timely  information  in  strategic  and  tactical  operations, 
as  well  as  optimum  use  of  Navy  sensors  and  weapons  systems  is  inhibited  by  the  limits 
of  current  Command,  Control  and  Communications  (C3)  systems  architecture  and  its 
associated  components. 

Observations 

The  shortcomings  of  Navy  combat  and  C3  computer  systems  reveal  vulnerabil¬ 
ity  in  warfighting  capability  and  survivability.  These  shortcomings  are  due  to  narrow 
range  and  lack  of  flexibility  in  support  of  numerous  tactical  afloat  and  ashore  users. 
The  limiting  factor  in  these  shortcomings  is  the  continued  development  of  uniquely 
Navy  systems.  C3  systems  designed  to  Military  Specifications  (MILSPEC)  force  the 
Navy  into  unrealistic  development  and  life  cycle  support  time  and  cost.  This  approach 
diverges  from  the  current  industry  utilization  of  Open  Systems  Architecture  (OSA)  and 
common  standards  that  facilitate  increased  growth  in  processing  while  decreasing 
costs.  In  contrast,  the  Navy’s  approach  requires  a  longer  lead  time  and  produces  less 
capable  and  costlier  C3  systems. 

Conclusions 

Implementation  of  OSA  is  the  best  method  of  reducing  development  time  and 
system  cost  while  using  leading  technology  and  improving  compatibility  between  Navy 
units,  other  service  branches  and  industry.  The  Panel  found  several  examples  of 
effective  use  of  OSA.  Most  notable  of  these  was  the  Naval  Tactical  Command  System  - 
Afloat  (NTCS-A).  In  addition,  the  endorsement  of  OSA  by  the  Copernicus  Architecture 
effort  of  the  Director,  Space  and  Electronic  Warfare  (OP-094)  represents  significant 
progress.  However,  examples  of  Commercial-Off-the-Shelf  (COTS)  items  being 
randomly  employed  throughout  a  system  in  order  to  claim  use  of  OSA  results  in  a  loss 
of  most  of  the  inherent  benefits. 

From  an  engineering  perspective,  the  Panel  found  no  technological  barriers  to 
adopting  OSA  and  industry  standards  in  combat  and  C3  systems.  Policy  and  cultural 
barriers  to  implementation  exist,  and  are  due  to  institutional  inertia  and  minimal 
understanding  of  OSA  applications  by  decision  makers. 

Recommendations 

As  was  evident  in  Desert  Storm  operations,  Navy  C3  must  obtain  dramatic 
increases  in  the  communications  bandwidth.  Expansion  into  commercial  satellites, 
antenna  design,  and  ashore  and  afloat  processing  and  display  systems  is  critical.  To 
expedite  this  conversion  to  COTS  technology,  particularly  with  computers  and 
software,  the  Panel  recommends  that  the  current  MILSPEC  waiver  policy  be  inverted 
to  require  a  waiver  for  procurement  of  MILSPEC  equipment.  In  addition,  education 
of  program  managers  and  decision  makers  regarding  advantages,  capabilities  and 
availability  of  commercial  products  should  be  provided. 
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Ruggedized  commercial  equipment  and  standards  should  be  the  norm  for  Navy 
C3  while  systems  designed  to  a  MILSPEC  should  require  a  waiver  for  use.  This  will 
ensure  optimum  fleet  readiness  in  the  future. 
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II.  TERMS  OF  REFERENCE 


Introduction 

The  primary  goal  of  this  study  was  to  ascertain  Navy’s  need  and  technological 
ability  to  move  toward  COTS  hardware  and  software  for  C3  and  combat  weapon 
systems.  By  employing  experts  from  industry  and  academia,  Navy,  represented  by 
OP-094  as  requirements  sponsor  and  the  Assistant  Secretary  of  the  Navy  (Research, 
Development  &  Acquisition  (ASN  (RD&A))  as  acquisition  sponsor,  wanted  industry’s 
perspective  on  Navy’s  conduct  of  requiring  and  acquiring  computer  hardware  and 
software. 

The  Terms  of  Reference  (TOR)  evolved  over  several  months  in  late  1990  and  early 
1991.  This  timeframe  overlapped  the  Gulf  War  between  Iraq  and  United  Nations 
coalition  forces.  This  conflict  exposed  numerous  C3  shortcomings  in  architecture  and 
engineering  and  was  one  of  the  focal  points  for  the  study. 

This  report  specifically  addresses  the  current  status  of  the  Navy  acquisition 
policy  relative  to  C3,  evaluates  Navy  C3  performance  in  Desert  Storm,  and  assesses 
the  ability  of  meeting  naval  warfare  needs  with  COTS  equipment.  Recommendations 
are  made  in  areas  of  accountability,  policy,  education,  and  acquisition. 
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DEFINITIONS 


INTRODUCTION 


COTS-HW 

Commercial-Off-The-Shelf-Hardware  -  Hardware  components  that  support 
a  broad  commercial  user  base  (Personal  Computers,  Work  Stations) 

COTS-SW 

Commercial-Off-The-Shelf-Software  -  Software  components  that  support 
a  broad  commercial  user  base  (UNIX™,  XWindows™,  SQL™,  MSDOS™) 

OSA 

Open  Systems  Architecture  -  systems  built  with  well  defined,  widely 
available  hardware  and  software  building  blocks 


COTS-HW  —  Commercial-Off-The-Shelf-Hardware 

The  term  Commercial-Off-The-Shelf-Hardware  has  become  commonly  used  to 
describe  components  that  can  be  purchased  from  commercial  vendors  and  used  to  fill 
a  system  requirement.  Generally,  the  components  considered  are  those  that  support 
a  broad  commercial  user  base.  Due  to  the  growth  of  open  systems  standards,  it  is 
possible  to  mix  vendor  equipment  types  to  build  up  a  complete  system.  Due  to  the 
large  user  community  and  strong  commercial  competition,  these  components  have 
generally  grown  into  reliable  systems.  These  systems  are  also  produced  by  the 
millions  in  Personal  Computers  (PCs)  and  workstations,  yielding  production  quanti¬ 
ties  far  in  excess  of  anything  Navy  would  produce. 

COTS-SW  —  Commercial-Off-The-Shelf-Software 

Just  as  hardware  components  have  grown,  software  building  blocks  have 
evolved  into  broadly  used,  easily  integrated  packages.  UNIX™  operating  system, 
X-WINDOWS™  graphics  display  software,  and  Standard  Query  Language  (SQL) 
relational  data  base  systems  are  examples  of  widely  used,  fully  functional  software 
components  that  greatly  simplify  the  task  of  building  modern  systems.  These 
packages  are  generally  very  affordable  and  reliable  due  to  the  large  user  base  they 
support.  Additionally,  they  are  continuously  improved,  and  upgrades  can  be 
purchased  at  low  cost. 
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OSA  —  Open  Systems  Architecture 

Open  Systems  Architecture  is  a  relatively  new  term  that  is  used  to  represent  the 
concept  of  developing  systems  from  hardware  and  software  building  blocks  provided 
by  a  variety  of  vendors.  This  concept  is  a  revolutionary  departure  from  the  previous 
practice  of  vendors  developing  systems  from  the  ground  up,  using  unique  (propri¬ 
etary)  equipment  lines.  Driven  by  user  demand,  vendors  are  now  producing  and 
integrating  components  that  are  compatible  with  internationally  defined  standards. 
This  results  in  the  capability  for  users  to  combine  vendor  equipments,  flexibly  develop 
system  capabilities,  and  upgrade  system  components  a  layer  at  a  time,  independent 
of  other  components  or  layers. 
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The  evolution  in  communications  over  the  last  decade  parallels  the  computer 
revolution  because  of  parallel  technologies.  Several  important  trends  must  now  be 
considered  in  the  future  Navy  systems. 

Firstly,  voice  communication  has  moved  almost  completely  away  from  the 
century  old  analog  technology  into  digital  technology.  Computers  provide  the  routing, 
switching  and  conversions  needed  in  a  digitized  voice  communications  system.  Many 
of  today’s  long-haul  land  based  communication  links  are  digital.  These  links  include 
microwave  satellites  and  fiber  optic  cabling  that  encircle  the  globe. 

Secondly,  digital  communications  have  spawned  the  proliferation  of  computer 
networks  and  information  systems  where  computers  talk  to  computers.  Electronic 
mail  and  voice  mail  systems  have  replaced  many  of  the  voice  and  hardcopy 
communications  of  large  corporations.  Computer  networking  requirements  have 
increased  as  the  technology  provides  more  capabilities  in  the  hands  of  the  end  users. 
With  increased  computer  capability  comes  increased  bandwidth  demands  that  the 
technical  communication  evolution  continues  to  provide. 

Finally,  the  computer  and  communication  evolutions  have  forced  commercial 
standardization.  The  mandatory  requirement  to  share  information  and  technology 
has  caused  the  emergence  of  layered  protocols.  These  protocols  are  designed  to 


provide  an  interoperable  ability  to  communicate  at  the  various  functional  layers,  even 
when  conversing  hardwares  are  dissimilar.  With  a  wide  number  of  vendors  imple¬ 
menting  this  hardware  and  software  technique,  Navy  can  reap  the  benefits  of  a  variety 
of  competing  sources.  In  order  to  capitalize  on  this  technology,  however,  Navy  needs 
to  depart  from  adapting  to  Tactical  Digital  Standards  (TADSTANDS)  and  adopt  the 
evolving  international  standards. 
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NAVY  STANDARDS  - 
UNIQUE  SYSTEMS 


INTRODUCTION 


OPNAVINST  5200.28  LIFE  CYCLE  MANAGEMENT  OF 
COMPUTER  RESOURCES.... 

"Standard  computer  hardware,  support  environments,  high  order 
languages  and  documentation  shall  be  used....TADSTANDs  establish 
standard...." 

TACTICAL  DIGITAL  STANDARDS  (TADSTANDs) 

TADSTAND  A  -  Definitions 

TADSTAND  B  -  Hardware  Standards  (Grey  Boxes) 

TADSTAND  C  -  High  Order  Languages  (Ada,  CMS-2,  etc.) 
TADSTAND  D  -  Reserves  Requirements  (50%) 

TADSTAND  E  -  Software  Development  /  Documentation  Standards 


Current  Navy  policy,  contained  in  the  OPNAV  Instruction  (OPNAVINST)  5200.28 
and  TADSTANDs,  mandates  the  use  of  fully  militarized  hardware  at  the  box  level.  Also 
included  in  existing  policy  are  prescribed  software  languages,  development  stan¬ 
dards,  and  reserve  capacity.  Though  these  policies  allow  pursuit  of  alternative 
computer  resource  solutions,  a  substantial  deterrent  effect  is  encountered  by 
program  managers  because  of  the  extensive  cost-effectiveness  analysis  which  must 
be  prepared  in  order  to  obtain  a  waiver  from  using  Navy’s  standards. 

These  policies  led  to: 

•  Submission,  use  of  Navy  standards  (even  though  it  may  not  be  the  most  cost 
or  time  effective  way  to  meet  requirements) . 

•  Passive  Resistance,  which  generally  uses  delay  tactics  to  assure  success 
of  waiver  requests. 

At  the  time  these  standards  were  initiated,  they  were  effective  at  solving  organic 
Navy  problems.  With  the  increased  emphasis  on  Joint,  Allied,  and  industry 
interoperability,  these  standards  are  no  longer  effective. 
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V.  INDUSTRIAL  REVOLUTION 
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Initial  manifestations  of  computer  and  communications  standards  emerged  in 
the  early  seventies,  largely  within  Department  of  Defense’s  (DoD’s)  Advanced  Re¬ 
search  Projects  Agency  Network  (ARPANET).  For  the  first  time,  a  communication 
system  was  being  developed  to  enable  computer  users  to  exchange  information.  Some 
of  the  early  Advanced  Research  Projects  Agency  (ARPA)  standards  focused  on  the 
electrical  interface,  bit  oriented  protocol  for  attaching  the  Automated  Data  Processing 
(ADP)  equipment  to  communication  computers.  Other  standards  were  initiated  to 
establish  a  common  control  language  for  the  diverse  terminals  that  would  be  using 
the  network.  As  traffic  grew  and  the  number  of  users  increased,  a  need  for  a  more 
efficient  data  control  protocol  elicited  development  of  the  Transmission  Control 
Protocol  and  the  Internet  Protocol  (TCP/IP)  specification.  This  was  eventually  adopted 
as  the  DoD  standard. 

TCP/IP  standards  were  important,  but  they  relied  on  the  original  analog 
connection  standard.  In  the  early  eighties,  the  International  Standards  Organization 
(ISO)  began  working  on  a  totally  layered  set  of  standards  known  as  the  ISO  Standards 
for  Open  Systems  Interconnect  (OSI).  These  standards  focused  on  a  larger  set  of 
issues  dealing  with  computers  and  communications.  The  lower  layers  solve  the 
communication  interconnection  problem.  The  upper  layers  solve  the  digital  computer 
interconnect  problem.  The  seventh  (top)  layer  addresses  the  common  application 
interface  standards,  thus  allowing  the  complete  flexibility  of  application  transport¬ 
ability. 
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For  the  first  time,  OSI  standards  allowed  different  manufacturers  to  develop 
products  for  different  layers  which  could  be  used  by  other  manufacturers.  The 
proliferation  of  products  in  computer  and  communication  systems  allows  industry  to 
use  the  building  blocks  from  many  companies.  This  phenomenon  will  not  only 
continue,  but  will  accelerate,  resulting  in  an  even  tighter  integration  of  communica¬ 
tions  and  ADP.  This  is  further  evidenced  in  the  Integrated  Services  Data  Network 
(ISDN)  standards  being  deployed  today.  These  standards  provide  integration  of  digital 
voice,  video,  and  data. 
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INDUSTRY  BECOMES  INTEROPERABLE 


INDUSTRIAL  REVOLUTION  k 

1985 


1991 


Unstandardized  Interfaces 

Few  Suppliers  Selling 
Total  Systems 

High  Cost-Low  Capability 

Computers  As  Systems 


>  Highly  Standardized  Interfaces 

>  Many  Suppliers  -  Selling 

Standard-Interface  Modules 

>  Low  Cost-High  Capability 

>  Computers  as  Components 


Unique  System  for  Each 
Need 


>  Tailored  to  Users  Needs  From 
Standard  Modules 


The  computer  is  the  epitome  of  “high  tech,”  but  until  a  few  years  ago  the 
computer  industry  itself  was  relatively  small  and  organized  almost  along  “cottage 
industry”  lines,  like  the  auto  industry  before  Henry  Ford,  or  the  aircraft  industry 
before  World  War  II.  As  technology  allowed  small,  affordable  PCs  to  be  built,  users 
began  to  require  more  application  software.  Vendors  were  driven  by  their  customers 
to  produce  interoperable  components.  Eventually  everyone,  including  vendors, 
began  to  benefit  from  this.  Today,  we  are  in  the  final  stages  of  a  true  “industrial 
revolution”  in  computer  hardware  and  software  which  has  totally  transformed  the 
industry.  Navy  has  no  choice  but  to  adopt  these  changes.  By  leveraging  the  industrial 
revolution,  Navy  can  reap  great  benefits  in  increased  capability  and  decreased  cost. 
If  Navy  continues  to  develop  unique  product  lines,  it  will  likely  face  spiraling  costs 
while  falling  further  and  further  behind  in  capability. 

The  key  to  these  changes  and  to  Navy’s  ability  to  use  them  to  advantage  is  OSA. 
The  open  systems  approach  discards  yesterday’s  monolithic  take-it-or-leave-it  total 
systems  approach.  Instead,  hardware  and  software  now  is  sold  in  modular  compo¬ 
nent  packages  with  highly  standardized  interfaces.  Integrators  can  use  these 
packages  to  assemble  systems  tailored  to  user  needs  quickly  and  inexpensively.  In 
today’s  environment  it  makes  no  sense  to  design  and  construct  unique,  specialized 
computer  hardware  or  software. 
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DoD  is  no  longer  the  dominant  acquirer  and  user  of  computer  technology.  DoD 
can  influence,  but  no  longer  dictate,  the  direction  of  technology  development. 
However,  by  riding  the  crest  of  computer  technology  development,  Navy,  in  particular, 
and  DoD,  in  general,  can  significantly  expedite  computer  system  development  and 
deployment,  increasing  deployed  system  performance,  and  reducing  costs. 
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Leaving  behind  the  era  of  systems  that  are  custom-made  to  meet  Navy’s  unique 
requirements  promotes  a  sense  of  losing  control,  but  the  benefits  to  Navy  are 
enormous. 

As  long  as  Navy  custom-tailors  systems  to  unique  specifications,  it  must  pay 
the  entire  cost  of  their  development,  production  and  support.  As  computer  systems 
grow  in  complexity,  these  costs  increase  substantially. 

When  Navy  buys  OSA  commercial  systems,  it  pays  only  a  fraction  of  the 
development  cost.  The  large  production  volume  of  open  systems  and  the  competitive 
environment  in  which  they  are  sold  drive  unit  costs  down  dramatically,  bringing  about 
substantial  savings.  Thus,  Navy  saves  twice,  in  development  cost  and  in  unit  cost. 

Savings  in  time  are  as  dramatic  as  savings  in  dollars.  A  system  can  be 
assembled  from  OSA  COTS  hardware  and  software  modules  in  months.  Compare  this 
to  the  years  required  to  design  and  build  turnkey  systems  to  meet  unique  Navy 
requirements.  Since  the  COTS  system  will  embody  far  newer  technology,  it  will  most 
likely  be  able  to  better  meet  Navy  needs.  The  quality  of  the  products  is  also  derived 
from  the  high  volume  of  production.  In  addition,  the  large  user  base  continually  tests 
and  refines  these  products.  Navy  unique  systems  are  limited  in  production,  volume, 
and  the  extent  of  testing  that  can  be  conducted. 
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WHY  COTS  SOFTWARE 
SAVES  MONEY  &  TIME 


_  INDUSTRIAL  REVOLUTION 

A  Typical  System  Consists  of: 

Non-COTS  (10  -  25%)  - 

•  Application  Specific  Code 
COTS  (75  -  90%) 

•  Operating  System 

•  User  Interface 

•  Network  and/or  Communication  Interfaces 

•  Device  Drivers 

•  Database  Manager 


10% 


The  “industrial  revolution  in  software”  has  led  to  a  fundamental  change  in  how 
software  can  be  created.  Just  a  few  years  ago,  fabrication  was  the  appropriate 
metaphor  because  most  software  systems  were  written  largely  from  scratch.  System 
developers  invariably  wrote  their  own  user  interfaces,  and  in  extreme  cases,  they  even 
had  to  add  basic  utilities  to  some  sort  of  raw  operating  system  kernel. 

Today,  however,  the  appropriate  metaphor  is  assembly.  System  developers 
can  build  their  systems  largely  by  combining  widely  used  components  tested  by  tens 
of  thousands  of  users,  thus  avoiding  work  on  generic  code  such  as  that  found,  for 
example,  in  user  interfaces. 

Accordingly,  system  developers,  i.e.  Navy,  can  concentrate  on  producing  more 
capable  applications  with  fewer  bugs  at  less  cost  because  the  ratio  of  supporting 
software  to  application  specific  software  is  almost  always  more  than  3:1.  A  more 
typical  figure  for  small  and  medium-sized  problems  is  9:1. 
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E  COTS  COMPARED  TO  MILSPEC 


INDUSTRIAL  REVOLUTION 


MIPS  /  $: 

•  About  100  X 
Technology: 

•  7-10  years  ahead 
Operator  interfaces: 

•  Decrease  training  time  and  expense 

•  Increase  operational  performance 
Quality: 

•  Varies  by  vendor 

•  Ruggedized  and  MILSPEC  available 


The  technology  in  MILSPEC  computers  is  approximately  seven  years  behind  the 
technology  in  current  COTS  computers.  This  means  that  MILSPEC  computers  are  at 
least  an  order  of  magnitude  slower  and  have  an  order  of  magnitude  less  memory  and 
disk  storage  than  current  COTS  computers.  Moreover,  given  the  limited  market  for 
many  MILSPEC  computers  and  their  high  development  cost,  they  are  at  least  an  order 
of  magnitude  more  expensive  than  COTS  computers.  Combining  these  two  factors 
provides  a  price/ performance  advantage  of  two  orders  of  magnitude  for  COTS 
computers. 

One  area  that  has  seen  rapid  development  and  standardization  over  the  past 
five  years  is  graphical  user  interfaces.  For  example,  the  emergence  of  X- WINDOWS™ 
and  Motif  are  having  a  major  impact  in  the  commercial  arena.  By  adopting  such 
graphical  standards,  Navy  can  avoid  the  development  and  maintenance  costs  while 
improving  the  functionality  of  human  interfaces.  Moreover,  the  use  of  such  standards 
will  promote  human  interoperability  and  efficiency  across  various  Navy  systems.  This 
will  significantly  decrease  training  expenses  while  increasing  flexibility  and  opera¬ 
tional  ability. 
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VI.  DESERT  STORM  OBSERVATIONS 
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Navy  faces  another  kind  of  resource  squeeze  which  can  also  be  alleviated  with 
the  use  of  commercial  approaches.  Desert  Shield/Storm  showed  clearly  that  Navy 
long-haul,  over-the-horizon  (OTH)  communications  are  grossly  inadequate.  Vital 
tactical  information,  such  as  joint  service  tasking  orders,  imagery  for  strike  targeting, 
and  inputs  for  retargeting  of  Tomahawk  Land-Attack  Missiles  (TLAM),  slowed  to  a 
trickle,  even  when  bandwidth  was  dedicated  to  these  purposes. 

Navy  is  well  behind  the  Army  and  Air  Force  in  available  bandwidth.  The  singular 
lack  of  aircraft  carrier  available  bandwidth  caused  a  significant  reduction  in  air  strike 
planning  time,  target  intelligence,  and  integration  of  carrier  forces  with  land  based 
forces. 

Navy  has  organized  its  communications  systems  to  support  the  nearly  autono¬ 
mous  operations  of  a  Battle  Group  (BG).  For  example,  very  little  bandwidth  was 
available  to  support  joint  service  operations  which  led  to  the  inability  to  electronically 
receive  the  Air  Tasking  Order  (ATO)  from  U.S.  Central  Command  (CENTCOM). 

OP-094  greatly  accelerated  the  fielding  of  numerous  C3  systems  in  deploying 
BGs  during  Desert  Shield/ Storm.  OP-094  has  initiated  a  number  of  extensive  efforts 
based  on  lessons  learned  from  the  Gulf  War.  Top  priority  is  to  increase  Navy  C3 
throughput  by  employing  Super  High  Frequency  (SHF)  communications.  During 
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Desert  Storm,  OP-094  installed  SHF  Satellite  Communications  (SATCOM)  in  USS 
BLUE  RIDGE,  BELKNAP,  NASSAU,  LASALLE,  and  USS  TARAWA.  SHF  provided  a 
major  leap  in  speed,  functionality,  anti-jam  and  reliability.  Without  SHF,  operations 
in  these  ships  would  have  slowed  down  because  of  slower  data  flow  and  the  taxed  state 
of  the  UHF  system. 

SHF  provided  direct-dial  secure  voice  capability  to  fleet  commanders,  vice¬ 
routing  through  the  Communications  Area  Master  Station  (CAMS)  switch.  It  also 
provided  connectivity  to  the  SHF  ground  mobile  force  terminals,  thereby  providing 
connectivity  between  forces  ashore  and  forces  afloat.  The  development  of  a  lightweight 
SHF  system  which  can  be  used  on  more  ships  (which  implies  antenna  sizes  on  the 
order  of  4  feet)  needs  to  be  identified  as  a  future  objective. 

The  performance  derived  from  SHF  installations  in  these  ships  was  more 
recently  provided  to  USS  ABRAHAM  LINCOLN  to  support  the  evacuation  operations 
in  the  Philippines. 
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KEY  FINDINGS  DESERT  SHIELD/STORM 


DESERT  STORM  OBSERVATION 


Navy  bandwidth  limited  by  dependence  on  vulnerable 
UHF 

•  Bandwidth  partitioning  (voice  and  data)  limited 
interoperability 

•  Joint  Service  record  traffic  at  75  bps  (CUDIXS) 

•  Imagery  support  is  inadequate 


Desert  Shield /  Storm  provided  insights  into  the  critical  need  for  communication 
of  large  volumes  of  information  (voice,  data,  images)  to  support  the  needs  of  decision 
makers  and  warfighters.  High  volume  transmissions  are  transmitted  over  UHF 
satellites  which  are  vulnerable  to  jamming.  Available  channels  are  rigidly  partitioned 
into  voice  and  data.  Demand  Assigned  Multiple  Access  (DAMA)  positions  data  into 
dedicated  nets  such  as  Tactical  Data  Information  Exchange  System  (TADIXS), 
Tactical  Intelligence  Information  Exchange  Subsystem  (TACINTEL),  and  Fleet  Imag¬ 
ery  Support  Terminal  (FIST) ,  which  are  not  compatible  with  the  other  services.  Record 
traffic  over  the  Fleet  Broadcast  (FLT  BCST),  which  is  common  to  all  services,  is  limited 
to  75  bits  per  second  (bps).  Transmission  and  management  of  imagery  is  provided  by 
the  FIST  which  does  not  provide  the  capability  to  transmit  and  receive  high  resolution 
images. 

In  summary,  these  examples  confirm  the  severe  limitations  of  Navy’s  commu¬ 
nications  capacity  that  were  observed  initially  in  UHF  satellite  circuits  and  later  in 
circuits  designed  to  disseminate  images  and  data  to  both  afloat  and  Marine  units. 
These  communication  shortfalls  need  attention  to  support  joint  forces  in  the  future 
battlefield  where  the  “contest  for  information”  will  likely  determine  the  victor. 
Commercial  satellite  systems  were  used  to  help  eliminate,  in  part,  some  of  these 
problems. 
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DESERT  STORM 
BANDWIDTH  CONSTRAINTS 


DESERT  STORM  OBSERVATION 


Record  Traffic  (e.g.,  CUDIXS,  FLT  BCST) 

Pre  -  Desert  Shield  /  Storm  During  Desert  Shield  /  Storm 


Avg 

Backlog 

90% 

Avg 

Backlog 

90% 

Flash 

0.6 

1.0 

8.6 

18.0 

Operation  Imm. 

2.9 

7.0 

8.7 

18.0 

Priority 

6.7 

19.0 

42.0 

135.0 

(all  units  in  hours) 
(CNA  Hot  Wash-up  data) 


With  the  commencement  of  Operation  Desert  Shield,  Navy  units  experienced 
significant  delays  in  receiving  record  message  traffic.  For  example,  the  backlog  at  the 
CAMS  serving  these  units  grew  to  36,000  messages  in  the  Western  Pacific  and  2 1 ,000 
in  the  Mediterranean.  This  surge  in  record  message  traffic  caused  large  delays  in 
delivery  of  these  messages  to  all  USN  assets  and  had  a  major  impact  on  afloat  units. 
This  chart  shows  the  time  delay  (from  message  date-time-group  to  time-of-receipt  by 
the  user)  in  record  message  traffic  at  different  precedent  levels  for  the  period  prior  to 
Desert  Shield/ Storm  and  during  Desert  Shield/ Storm. 

Several  Total  Quality  Management  (TQM)  actions  were  taken  to  significantly 
reduce  the  excessive  backlogs  in  record  traffic  during  Desert  Shield.  Message 
screening  boards  were  established,  worldwide  “minimize”  was  implemented,  addi¬ 
tional  Common  User  Data  Information  Exchange  System  (CUDIXS)  suites  were 
brought  on-line,  and  several  software  modifications  were  made  to  the  message 
processing  system.  At  the  start  of  Operation  Desert  Storm,  another  major  increase 
in  the  volume  of  flash  message  traffic  caused  backlogs  to  grow  which  persisted  into 
the  first  week  of  the  air  war. 
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DESERT  STORM  BANDWIDTH 
CONSTRAINTS  (Cont.  2) 


DESERT  STORM  OBSERVATION 


TLAM  mission  data  updates  (e.g.,  TADIXS  /  OTCIXS) 

•  Median  of  4  hrs  net  time 

•  As  long  as  16.5  hrs 

Secondary  imagery  dissemination  (via  FIST)  is  only  low 
resolution 

•  Transmit  /  receive  of  high  resolution  is  not 
supportable 


Air  tasking  order  (e.g.,  CUDIXS,  FLT  BCST) 
•  On  order  of  5  hrs 


All  mission  data  updates  for  the  TLAM  were  sent  to  firing  platforms  via  Officer 
In  Tactical  Command  Information  Exchange  Service  (OTCIXS)  and/or  (TADIXS-A), 
thus  limiting  the  use  of  these  nets  for  other  tactical  purposes.  These  updates  required 
a  median  of  4  hours  of  net  time  and  occasionally  removed  the  net  from  other  tactical 
use  for  as  long  as  16.5  hours. 

Current  fleet  communication  bandwidth  and  shipboard  antenna  characteris¬ 
tics  prohibit  transmission  of  digital  imagery  to  afloat  units  in  acceptable  volume  and 
resolution.  Currently,  FIST  is  limited  to  receiving  low  resolution  imagery  (512x512 
pixels)  and  does  not  satisfy  afloat  imagery  exploitation  requirements.  Transmission 
of  hi-resolution  imagery  products  (37  to  150  megapixels)  would  require  in  the  order 
of  80  hours  at  current  2400  baud  capacity. 

No  electronic  solution  was  found  for  disseminating  the  ATO  to  afloat  units. 
Several  alternative  methods  were  tested  but  yielded  only  marginal  improvements  by 
the  end  of  Desert  Storm.  Navy  found  that  the  best  way  for  assured  distribution  of  the 
ATO  was  to  fly  an  organic  fixed  wing  carrier-ased  aircraft  (S-3)  to/from  Riyadh,  Saudi 
Arabia,  return  it  to  the  carrier,  and  subsequently  deliver  it  to  other  BG  units  via 
helicopter.  Similar  problems  with  the  ATO  were  experienced  by  the  Marine  Expedi¬ 
tionary  Forces  (MEFs),  but  were  quickly  resolved  due  to  the  availability  of  an  SHF 
Ground  Mobile  Facility  (GMF)  which  was  interfaced  to  the  COTS  Local  Area  Network/ 
Wide  Area  Network  (LAN/ WAN)  Desert  Storm  Hub. 
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COMMERCIAL  SATCOM  IN 
DESERT  SHIELD/STORM 


DESERT  STORM  OBSERVATION 


Commercial  SATCOM  used  to  work  around  data 
transmission  deficiencies 

•  Interoperability  with  MIF  (Maritime  Interdiction 
Forces) 

•  Transfer  of  large  quantities  of  administrative  data 

•  Logistics  support 


The  International  Maritime  Satellite  (INMARSAT)  System  served  as  a  vital  link 
for  coordinating  the  efforts  of  Commander,  U.S.  Navy  Central  Command 
(COMUSNAVCENT)  on  USS  BLUE  RIDGE  and  Commander,  Naval  Central  Command 
Riyadh  (NAVCENT  RIYADH).  It  was  also  used  for  real  time  coordination  of  the  ATO 
input  between  the  Navy  Joint  Forces  Air  Component  Commander  (JFACC)  represen¬ 
tatives  and  the  Arabian  Gulf  Battle  Force  Commander  on  board  USS  MIDWAY.  (The 
Red  Sea  battle  force  commander’s  flagship  did  not  have  an  operational  INMARSAT 
until  late  in  the  war.)  INMARSAT  was  often  the  only  communications  circuit  common 
to  coalition  force  ships.  The  Aviation  Supply  Office  (ASO),  Philadelphia,  discovered 
that  it  was  more  efficient  to  transfer  its  large  data  files  using  INMARSAT  rather  than 
the  military  message  system.  One  current  limitation  is  INMARSAT  cannot  be  used 
with  Secure  Telephone  Unit  (STU)  Ills  in  a  broadcast  mode  to  disseminate  encrypted 
data  to  several  ships  simultaneously  (nor  exchange  military  operational  data). 

Defense  Advanced  Research  Projects  Agency  (DARPA)  completed  technical 
testing  of  a  demonstration  lightweight  communications  satellite  called  Multiple 
Access  Satellite  (MACSAT)  just  as  communications  overloading  became  a  problem  in 
Desert  Shield.  This  MACSAT,  fabricated  from  COTS  components,  was  called  into 
service  by  the  Marine  Corps  during  Desert  Shield/ Storm  to  exchange  critical  logistics 
data  with  the  forces  in  the  Gulf. 
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Other  commercial  satellite  systems  (e.g.,  Skynet,  PAN  AM)  were  employed  by  the 
U.S.  to  link  CENTCOM  C3  nodes  with  National  Command  Authorities  (NCA). 
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AMPHIBIOUS  COMMUNICATIONS 


DESERT  STORM  OBSERVATION 


UHF  limited  to  one  voice  channel  (allocation  by  CINCCENT) 
HF  limited  by  atmospheric  problems 
Land-based  Marine  communications  adequate 


•  LAN  /  WANS  (COTS) 

•  DSCS(SHF) 

•  VHF  Local  Communications 


At  the  onset  of  the  deployment,  single  channel  radio  was  the  primary  means  of 
communication  both  internal  and  external  to  the  Marine  Air  Ground  Task  Force 
(MAGTF).  Rapidly  installed  single  channel  HF,  VHF,  and  UHF  satellite  circuits 
provided  connectivity  for  the  7th  Marine  Expeditionary  Battalion  (MEB).  Further, 
UHF  single  channel  satellite  communications  was  initially  the  only  link  to  CENTCOM 
in  Riyadh,  Saudi  Arabia.  Commercial  telephone  was  available.  As  the  multichannel 
communication  system  developed  with  expanded  GMF  satellite  and  microwave 
networks,  the  single  channel  radio  network  became  a  secondary  means  of  communi¬ 
cations.  Nevertheless,  throughout  the  operations,  single  channel  radio  provided 
reliable  service  for  the  MAGTF  at  many  critical  times. 

Because  of  the  force  separation  from  the  MAGTF  command  element,  the  GMF 
satellite  communication  SHF  network  offered  the  most  reliable  means  of  both  internal 
and  external  connectivity.  Consequently,  the  focus  of  the  battalion  effort  quickly 
changed  from  single  channel  radio  in  the  initial  phase  to  interfacing  with  the  GMF 
network  via  a  COTS  LAN/ WAN.  This  network  served  as  the  primary  Marine  Corps 
ashore  command  and  control  system.  This  communications  network  is  discussed 
later  as  a  COTS  success  story.  However,  despite  the  number  of  alternative  commu¬ 
nication  paths  available  to  the  Marines,  in  the  event  that  an  opposed  amphibious 
landing  was  to  be  conducted,  only  a  single  UHF  voice  channel  would  have  been 
available  to  support  the  operation. 
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VII.  SUCCESS  STORIES 
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TRANSITION  COMPARISON 


SUCCESS  STORIES 


PRE-PARADIGM  SHIFT 
(ACDS  BLK  I) 

•  UTILIZE  AVAILABLE  HARDWARE 


•  OPERATING  SHELL  NEEDED  FOR 
EXECUTIVE 

•  DISPLAY  SCREEN  S/W  TOOLS 
UNAVAILABLE 

•  UNIQUE  S/W  SUPPORT 
REQUIREMENTS 

•  MIL-  LOGISTICS  SUPPORT 

•  TEN-YEAR  CYCLE  TO  A  WORKING 
PROTOTYPE  (150  MAN  YEARS) 

•  CV  CONFIGURATION  -  $20M 


POST-PARADIGM  SHIFT 
(NTCS-A) 

UTILIZE  LATEST  GENERATION 
HARDWARE  -  NDI  and  COTS 

COMPLETE  OPERATING  SYSTEM 
AVAILABLE 

SCREEN  LANGUAGE  &  S/W 
TOOLS  AVAILABLE 

STANDARD  S/W  SUPPORT 


COMMERCIAL  SUPPORT  BASE 

ONE-YEAR  CYCLE  TO  A  FIELDED 
SYSTEM  (15  MAN  YEARS) 

CV  CONFIGURATION  -  $1 ,8M 


During  the  course  of  this  study,  briefings  were  provided  addressing  numerous 
on-going  programs.  Two  programs  of  roughly  equivalent  functionality  are  compared 
here.  Since  their  initiation  is  separated  by  the  paradigm  shift  boundary  of  Navy 
unique  versus  OSA,  they  represent  what  “was”  and  what  “can  be.”  A  comparative 
evaluation  of  these  two  programs  is  instructive  from  several  perspectives. 

Firstly,  using  Navy  unique  hardware,  a  pre-shift  norm,  because  it  is  a  sunk  cost 
and  mandated,  will  be  very  expensive  in  today’s  environment.  Getting  the  equipment 
to  fulfill  its  desired  functional  role  within  currently  acceptable  standards  will  require 
considerable  time  and  money. 

Secondly,  industry  has  reached  the  consensus  that  the  development  of 
proprietary  (unique)  operating  systems  as  well  as  display  screen  tools  for  each 
application  is  a  dead-end  path.  This  consensus  has  been  a  real  forcing  function  in 
moving  from  the  old  to  the  new  order  in  the  commercial  market  place.  Product  viability 
is  being  driven  by  productivity  requirements. 

Thirdly,  the  issue  of  the  reliability  and  maintainability  of  software  cannot  be 
overlooked.  Documentation  of  a  unique  operating  system  is,  at  best,  difficult. 
Further,  given  a  small  core  of  users,  identification  and  resolution  of  any  new  problem 
is  critically  dependent  upon  a  few  experts  and  does  not  occur  during  production, 
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rather  errors  are  identified  in  the  fielded  system.  When  there  is  not  a  large 
constituency  for  making  and  keeping  things  right,  an  environment  for  generating 
large  costs,  lengthy  fielding  delays  and  reduced  operational  ability  is  created. 

Finally,  by  the  time  a  ten-year  development  cycle  is  completed,  what  may 
originally  have  been  a  state-of-the-art  conceptual  system  has  become  obsolete.  When 
one  does  not  drive  the  state-of-the-art,  the  only  prudent  policy  is  to  use  the  output  of 
those  who  do. 
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COTS:  AT  SEA 


_  SUCCESS  STORIES 

COTS  AND  MILSPEC  SIDE-BY-SIDE 

Favorable  reports  from  fleet 

•  Operability 

•  Reliability 
Four  major  casualties 

•  USS  Stark  -  2  Exocet  Missile  Hits 

•  USS  Samuel  B.  Roberts  -  Mine 

•  USS  Princeton  -  2  Mines 

•  USS  Tripoli  -  Mine 


Most  of  our  ships  today  have  both  COTS  and  MILSPEC  systems,  often  placed 
or  sitting  alongside  each  other  in  the  same  space.  Fleet  users  universally  endorse  the 
COTS  systems’  operational  value,  ease  of  use,  and  reliability.  Their  only  real  concerns 
are  for  logistic  support  —  concerns  we  believe  can  easily  and  economically  be  resolved. 
Each  of  the  four  ships  which  suffered  major  battle  damage  in  the  Arabian  Gulf  over 
the  past  few  years  had  many  spaces  in  which  COTS  and  MILSPEC  systems  stood  side 
by  side.  Some  systems  were  destroyed,  some  survived  but  were  put  out  of  action, 
although  most  survived  and  continued  to  function.  We  could  find  no  instances  in 
which  a  COTS  system  failed  while  a  MILSPEC  system  survived  comparable  damage. 
Nor  could  we  find  a  case  where  eitherCOTS  orMILSPEC  information  systems  were  a 
limiting  factor  in  the  ship’s  ability  to  continue  to  fight.  Damage  to  the  platform  itself 
was  the  real  problem.  We  expect  that  this  will  continue  to  be  true  in  this  era  of 
increasingly  powerful  weapons .  We  believe  the  “ilities”  and  state-of-the-art  computing 
capabilities  of  COTS  will  increase  combat  systems’  capabilities,  thereby  contributing 
significantly  to  the  Fleet’s  ability  to  defeat  threats  before  they  can  harm  our  ships.  The 
following  paragraphs  detail  two  recent  examples: 

USS  PRINCETON 


USS PRINCETONwa.s  subject  to  two  influence  mines  during  Operation  Desert 
Storm.  The  first  mine  caused  damage,  while  the  second  mine  was  too  far  from  the  ship. 
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This  first  mine  detonated  directly  beneath  the  stern  resulting  in  localized  damage  due 
to  initial  shock  levels  above  designed  keel  shock  factors.  Other  structural  damages 
occurred  due  to  whipping  factors. 

Keel  shock  factors  were  rapidly  dampened  so  that  shock  and  vibration  values 
were  negligible  upon  arrival  in  the  combat  direction  spaces.  While  60  Hz  and  400  Hz 
power  were  continuously  available,  isolated  power  interruptions  did  cause  both 
MILSPEC  and  COTS  computing  systems  to  drop  off  line.  These  systems  were 
manually  restarted  within  2-4  minutes  with  no  damages  to  either  COTS  or  MILSPEC 
systems. 

There  were  no  discernable  survivability  differences  between  MILSPEC  and 
COTS  computing  systems. 

USS  STARK 


The  U  SS  STARK  suffered  damage  from  two  Exocet  missiles  fired  from  an  Iraqi 
F-l  Mirage  in  1987.  These  Exocets  struck  in  combat  areas  and  caused  extensive 
destruction  to  both  MILSPEC  and  COTS  systems.  The  initial  shock  of  impact  severely 
damaged  both  computing  systems.  The  MILSPEC  systems  was  no  more  survivable 
than  the  COTS  system  in  this  situation. 
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COTS:  IN  THE  AIR 


SUCCESS  STORIES 


Example:  STRAP  ADM 

•  Almost  all  COTS 

•  Flies  aboard  fleet  P-3C 

•  No  failures 

•  14  months,  $450 K 


•  420  MFLOPS,  384  MBYTES  RAM 


COTS  has  not  as  yet  seen  use  in  aircraft  as  widely  as  aboard  ship.  We  would 
not  expect  or  urge  that  COTS  be  seen  as  a  broadly-applicable  substitute  for  specialized 
avionics  systems  at  this  time,  since  many  aircraft  impose  environmental  demands 
which  can  not  be  met  by  current-technology  COTS  systems,  even  with  special 
packaging  and  mounting. 

Many  other  avionics  systems,  however,  operate  in  crew  compartments.  It  is 
wasteful  to  require  these  systems  to  survive  any  environmental  stress  that  would 
render  the  crew  inoperative  —  and  in  general,  high-quality  COTS  systems  can  readily 
be  made  to  survive  the  same  stresses  as  a  human.  COTS  has  the  potential  to  fill  many 
of  the  needs  for  avionics  to  operate  in  conditioned  compartments.  With  minor 
modifications  COTS  can  meet  specific  needs  of  the  aircraft  environment.  This  is 
particularly  important  because  many  crew-compartment  avionics  systems  are  de¬ 
voted  heavily  to  operator  interface,  an  area  where  the  superiority  of  COTS  is  especially 
marked. 

STRAP  ADM 

An  example  of  airborne  COTS  is  provided  by  the  Advanced  Development  Model 
(ADM)  for  the  Sonobuoy  Thinned  Random  Array  Program  (STRAP).  STRAP  is  an 
innovative  and  advanced  Naval  Ocean  Systems  Center  (NOSC)  concept  for  achieving 
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very  high  gain  and  directivity  in  an  air-deployed  passive  or  bistatic  active  acoustic 
surveillance  system.  To  demonstrate  this  concept,  the  ADM  had  to  have  far  more 
advanced  acoustic  processing  capabilities  than  anything  currently  deployed  in  the 
Fleet,  and  yet  be  mountable  in  an  unmodified  fleet  aircraft  for  testing.  By  using  COTS 
hardware  and  software,  NOSC  was  able  to  assemble  a  420  Million  Floating  Points  of 
Operations  per  Second  (MFLOPS)  system  in  14  months.  The  equipment  costs  only 
$450,000  per  set.  The  ADM  flies  aboard  a  Fleet  P-3C  aircraft  and  has  operated  without 
failure  in  this  environment.  The  P-3  UPDATE  IV  is  the  next  generation  advanced 
acoustic  processing  and  display  system.  The  fielded  ADM  has  about  half  of  the 
capacity  of  the  UPDATE  IV  system,  currently  under  developjment. 


52 


COTS:  IN  THE  AIR 


SUCCESS  STORIES 


Example:  Beartrap  /  APEX 

•  Long  experience  aboard  fleet  P-3 

•  Good  reliability,  operability,  durability 

•  New  APEX  system  virtually  all  COTS 

•  Major  cost  and  schedule  savings 


BEARTRAP/APEX 

Another  good  example  of  COTS  application  in  aircraft  is  the  wide  variety  of 
COTS  equipment  used  by  Project  BEARTRAP  for  computing  and  display  functions 
over  the  past  several  years.  BEARTRAP  was  led  to  COTS  to  answer  its  need  for  a  very 
flexible,  highly  capable  processing  and  display  environment  for  investigation  of 
innovative  acoustic  and  non-acoustic  techniques  for  airborne  Anti-Submarine  War¬ 
fare  (ASW).  BEARTRAP  COTS  systems  have  flown  for  hundreds  of  hours  in  fleet  P-3 
aircraft,  often  from  forward  bases.  The  capability  provided  by  COTS  has  been  far  in 
advance  of  that  achievable  with  MILSPEC  systems;  reliability  and  durability  have 
been  satisfactory,  and  savings  in  time  and  money  have  been  immense. 

The  BEARTRAP  project  produced  many  valuable  lessons  learned  in  how  to 
successfully  apply  COTS  in  the  airborne  environment.  This  knowledge  has  been 
applied  in  developing  BEARTRAP  advanced  ASW  Prototype  Experimentation  (APEX) 
system,  a  100%  COTS  system.  APEX  uses  a  variety  of  COTS  equipment  interfaced  to 
FUTURE+  and  VME  buses  to  create  a  system  with  four  to  ten  times  as  much 
processing  throughput  as  the  P-3  UPDATE  IV  at  a  unit  cost  of  no  more  than  $2.5M  - 
less  than  20%  of  the  cost  of  an  UPDATE  IV  system. 

Note:  This  is  meant  only  as  a  point  of  reference;  APEX  has  a  mission  which  is 
different  from  that  of  UPDATE  IV  and  can  not  be  substituted  for  UPDATE  IV. 
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COTS:  IN  THE  FIELD 


SUCCESS  STORIES 


Example:  Marine  HMMV  Mobile  Communications 
System 

•  Brigade  LAN  /  WAN  port 

•  COTS  computing 
Example:  MOCC 

•  Air-transportable  Anti-Submarine  Warfare 
Operations  Center  (ASWOC) 

•  Full  COTS 


$1 .5M  vice  $13M 
3  in  Desert  Storm 


COTS  has  seen  wide  use  in  very  demanding  mobile  operations  ashore.  Two 
systems  illustrate  the  range  of  applications. 

In  direct  response  and  preparation  for  Desert  Shield/ Storm,  and  to  provide 
their  forward  brigades  with  access  to  their  terrestrial  local  area  and  wide  area 
networks  (WAN/ LAN),  the  Marines  assembled  a  system  using  COTS  processing.  This 
mobile  communications  system  used  a  combination  of  a  backbone  WAN,  made  up  of 
a  series  of  22  8  ft  and  20  ft  microwave  antennas  and  other  equipment.  This  system 
was  carried  throughout  Desert  Shield/ Storm  in  Marine  High  Mobility  Multipurpose 
Vehicles  (HMMVs)  without  any  significant  failures.  The  HMMVs  with  standard  COTS 
Z-248  PCs,  keyboards,  printers,  and  KG  series  crypto  equipment  would  link  into  the 
WAN.  Interoperability  was  provided  because  their  COTS  equipment  use  industry 
standards.  Preventive  maintenance  consisted  of  blowing  the  sand  out  of  the 
equipment  daily  with  a  commercial  air  compressor. 

The  COTS  hardware /  software  system  was  reliable  throughout  the  spectrum  of 
combat  and  environmental  stress  factors.  The  communications  suite  allowed  real¬ 
time  processing  of  tasking  and  maneuvering  orders,  including  the  ATO,  received 
through  the  mobile  COTS  microwave  WAN. 

The  Mobile  Operations  Control  Center  (MOCC)  provides  an  air-transportable 
capability  to  support  forward-deployed  Maritime  Patrol  Aircraft  (MPA)  squadrons. 
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The  MOCCs  depend  almost  entirely  on  COTS  to  perform  their  functions  of  mission 
planning  and  crew  briefing,  communications,  acoustic  analysis,  intelligence  analysis 
and  mission  reconstruction.  MOCCs  have  been  deployed  in  support  of  many  MPA 
operations,  including  three  units  deployed  for  Desert  Shield/ Storm  with  high 
reliability.  The  cost  per  MOCC  system  is  $  1 . 5  million,  compared  to  an  estimated  $  1 3 
million  for  an  equivalent  MILSPEC  system. 
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VIII.  CONCLUSIONS 
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CONCLUSIONS 


OS  A,  COTS  hardware,  and  COTS  software  can: 

•  Meet  the  growing  need  for  "information" 

-  60-80%  less  development  time 

•  Capture  commercial  advances 

-  Technology  doubling  every  18-36  months 

•  Adjust  to  smaller  budgets 

-  75%  less  development  cost 


•  Facilitate  system  "Interoperability" 

-  Navy- Navy;  Navy-Services;  Navy-Industry 


There  is  little  question  that  in  the  immediate  future  we  will  continue  to  see  rapid 
expansion  in  the  amount  of  information  needed  to  conduct  military  operations.  This 
expansion  will  be  generated  by  the  need  for  more  precise  and  timely  information  about 
all  phases  of  both  strategic  and  tactical  operations.  The  ability  to  integrate  all-source 
information  into  real  or  synthetic  video  will  place  heavy  demands  on  both  communi¬ 
cation  and  computational  resources  in  Command  and  Control.  At  the  same  time,  the 
real-time  requirements  for  target  detection,  classification,  assignment  and  weapon 
guidance  will  see  corresponding  growth. 

It  is  also  apparent  that  mission  effectiveness  will  depend  increasingly  upon 
software.  This  dependence  mandates  the  development  of  better  software  tools.  These 
tools  will  enable  rapid,  effective,  mission  dependent  modifications  to  critical  software 
(e.g.,  Patriot  vs.  Scud).  Hardware  life  will  be  extended  via  software  upgrades. 

One  needs  only  to  observe  the  short  time  between  the  introduction  of  each 
generation  of  workstations  and  increased  capabilities  of  their  backward  and  forward 
compatible  software  to  understand  the  existing  environment  for  change.  Application 
software  will  become  long  lived  as  it  migrates  from  one  computing  platform  to  another 
in  the  line  of  Open  Systems. 

Given  the  fact  that  there  will  be  fewer  new  start  programs,  emphasis  must  be 
placed  upon  the  increased  use  of  system  updates  to  maintain  technical  viability.  In 
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addition,  by  adopting  compatible  hardware  and  software  standards,  the  flexible 
manufacturing  capabilities  of  the  commercial  world  can  be  readily  used  in  times  of 
crisis. 


If  there  is  any  chance  for  the  command,  control,  communications,  and 
intelligence  (C3I)  community  to  remain  at  “state-of-the-art”,  advantages  must  be 
taken  of  this  rapid  commercial  growth.  The  DoD  budget  is  declining.  The  facts  are 
that  the  1991  DoD  budget  shows  a  projected  drop  of  29.6%  in  real  dollars  through 
1995.  Defense  spending  will  comprise  only  18%  of  the  Federal  budget  which  is  down 
from  28%  in  the  1980’s  and  is  comparable  to  the  level  in  the  late  1930’s. 

Hard  documented  evidence  was  not  available  on  the  possible  savings  realized 
when  building  COTS  systems.  Yet,  anecdotal  evidence  gathered  from  operating, 
development,  and  sponsor  organizations,  as  well  as  the  collective  business  and 
technical  expertise  of  this  Panel,  indicates  the  numbers  shown  here  are  valid  and 
conservative.  Development  time  is  reduced  60-80%  primarily  because  COTS: 
1)  eliminates  time  devoted  to  correcting  and  changing  equipment  functions;  2)  the 
COTS  supporting  software  eliminates  the  need  to  develop,  change  or  modify  all  but 
the  application  software;  and  3)  COTS  provides  highly  automated  system  develop¬ 
ment  support  environments.  These  same  reasons  allow  the  cost  savings  to  be  reduced 
by  at  least  75%  because  development  time  is  directly  associated  with  program  cost. 

The  fact  that  technology  is  doubling  every  1 8-36  months  is  cause  to  believe  that 
these  numbers  are  very  conservative.  In  the  early  years  of  computer  technology, 
technology  advances  were  always  utilized  to  improve  system  performance.  With 
today’s  powerful  machines,  many  of  the  technology  advances  are  being  allocated  to 
improving  system  reliability  and  to  facilitate  system  and  software  development.  This 
condition  is  improving  development  productivity  with  each  new  generation  of  equip¬ 
ment. 


In  addition  to  the  cost,  performance,  and  reliability  advantages  obtained 
through  the  use  of  OSA  and  COTS,  one  more  large  advantage  accrues.  OSA  will 
provide  the  communications  and  computational  sub-systems  access  to  each  other 
through  a  wide  variety  of  industry  standards.  Since  by  definition  COTS  equipment 
will  also  comply  with  these  standards,  the  widest  level  of  system-system  and  service- 
service  interoperability  can  be  obtained.  The  current  DoD  Common  Operating 
Environment  (COE)  effort  is  possible  precisely  because  each  of  the  services  are  using 
similar  commercial  standards  and  protocols.  With  very  little  effort  they  are  refining 
the  definitions  of  which  standards  and  protocols  are  acceptable  as  common  and  hence 
interoperable. 
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NOTED  EFFORT 


CONCLUSIONS 


Copernicus  Architecture  embraces  OSA  /  COTS 

•  Needs  more  emphasis  on  joint  and  industry 
interoperability 

•  CSS  deviating  from  OSA  /  COTS  standards 


The  Copernicus  Architecture  was  developed  by  OP-094  to  provide  an  “operator 
centered”  system  to  process  and  distribute  the  enormous  amount  of  information 
required  by  modern  warfare.  The  Copernicus  concept  proposes  to  support  Navy’s 
Command,  Control,  Communications,  Computers,  and  Intelligence  (C4I)  functions  by 
systematically  integrating  the  afloat  and  ashore  commanders  with  modern  “informa¬ 
tion  processing”  and  “information  distribution”  capability.  These  functions  are  ideally 
suited  to  the  leveraging  of  commercial  OSA  technology.  This  technology,  built  around 
the  concept  of  layered  protocols  such  as  the  ISO/OSI  Standards,  is  intended  to  bring 
commercial  data  processing  and  data  transfer  into  an  integrated  set  of  equipments 
and  associated  software. 

Navy  can  capitalize  on  this  commercial  technology  by  managing  both  informa¬ 
tion  processing  and  information  management  under  a  more  unified  structure  than 
currently  exists.  Initiatives  such  as  the  COE  could  then  be  coordinated  across  these 
programs,  thereby  encouraging  the  use  of  commercial  hardware  and  software 
solutions  to  support  an  interoperable  information  environment.  Navy’s  Operations 
Support  System  (OSS)  and  NTCS-A  programs  provide  good  starting  points  for  this 
initiative.  These  programs  are  correctly  moving  to  incorporate  COTS  and  ruggedized 
COTS  equipment  within  the  open  system  framework. 

The  Communications  Support  System  (CSS)  program,  while  aiming  to  use  an 
open  system  structure  for  processing  equipment,  is  not  taking  full  advantage  of 
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commercial  communications  technology  to  augment  the  military  communications 
systems.  This  inability  to  fully  exploit  commercial  standards  can  be  traced  to  Navy’s 
low  bandwidth.  Low  bandwidth,  with  commensurate  low  data  rates,  requires  much 
greater  protocol  efficiency.  Commercial  protocols  can  not  efficiently  use  the  low 
bandwidth  available  to  Navy.  Another  reason  CSS  is  using  Navy  standards  is  because 
it  must  link  Navy  unique  communications  systems.  As  commercial  communications 
systems  are  fielded,  CSS  will  not  be  able  to  fully  exploit  their  functions  and 
interoperability  unless  it  adopts  commercial  OSI  standards. 

Desert  Shield/ Storm  demonstrated  the  value  of  using  commercial  communica¬ 
tions  systems  to  augment  the  joint  military  systems.  In  Navy’s  case,  the  available 
bandwidth  from  shore  to  ship  and  ship  to  ship  are  so  limited  that  they  create  a  major 
impediment  to  future  information  transfer  growth,  smarter  use  of  existing  bandwidth, 
not  withstanding. 

Commercial  satellite  systems  such  as  INMARSAT,  Intelligence  Satellites 
(INTELSAT)  or  Direct  Broadcast  Satellites  (DBS)  should  be  immediately  used  to 
augment  Navy  communications.  Even  the  military  purchase  of  commercial  satellites  / 
channels  to  improve  ocean  coverage  may  be  cost  effective. 
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COMBAT  SYSTEM  EVOLUTION 


CONCLUSIONS 


The  advantages  of  OSA  /  COTS  apply  to  combat 
systems 

•  Significant  technical,  schedule,  and  cost  advantages 

•  Many  functions  common  to  C  systems 

•  Common  man-machine  interfaces 


-  Reduce  training 

-  Improve  operator  efficiency 


In  addition  to  understanding  Navy’s  use  of  COTS  in  C3  systems,  this  Panel 
investigated  current  Navy  practices  for  the  development  of  combat  systems,  specifi¬ 
cally  Combat  Direction  Systems  (CDS)  such  as  the  Advanced  Combat  Direction 
System  (ACDS)  currently  being  developed  for  surface  combatants,  amphibious  ships, 
and  aircraft  carriers.  The  Panel  acknowledges  these  control  programs  cannot  avoid 
Navy  unique  interfaces  and  protocols  used  with  existing  weapon  systems. 

However,  the  indications  and  warning  (I&W)  and  queing  side  of  these  CDSs 
must  interface  with  C3  systems  now  using  open  architectures.  This  promotes  a 
natural  expansion  path  for  the  combat  systems.  By  growing  new  or  expanding 
existing  functionality  into  open  system  machines,  Navy  can  capture  all  of  the 
advantages  of  the  COTS  system  including:  improved  man-machine  interfaces, 
tremendously  more  powerful  workstations,  reduced  procurement  times  and  costs, 
and  shared  functionality  with  C3  systems.  As  time  goes  on,  the  “open  system”  end 
of  the  combat  systems  could  grow  toward  the  weapon  system  interfaces  and  either 
accommodate  Navy  unique  interfaces  for  the  life  of  the  weapon  system  or  replace  the 
interfaces  in  subsequent  upgrades. 

In  the  case  of  new  combat  system  developments,  the  Panel  strongly  recom¬ 
mends  that  open  architecture,  using  COTS  systems,  be  considered.  The  margin  of 
technology  provided  by  OSA  COTS  can  significantly  improve  the  control  of  weapon 
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systems,  reduce  training  requirements,  and  improve  operator  efficiency.  Unlike  the 
early  days  of  combat  system  automation,  today’s  operators  are  computer  literate. 
Many  of  them  have  PCs  that  are  more  powerful  than  the  equipment  they  operate  in 
the  Navy.  Operators  understand  the  level  of  sophistication  available  in  modern 
display  technology.  They  also  understand  their  handicap  with  using  older  technology, 
better  educated  operators  are  fighting  very  sophisticated  weapons  with  last  decades 
technology.  Neither  retention  nor  survivability  bode  well  in  this  lose-lose  environ¬ 
ment. 
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IX.  BARRIERS  TO  COTS 
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POLICY  BARRIERS 


BARRIERS  TO  COTS 


Direct  Policy  Barriers 

•  Navy  standard  computers  mandated 

•  TADSTANDs 

•  Ada  mandated 

•  Waivers  required  for  deviation 

•  No  established  COTS  advocate 


Separation  of  the  “Policy  Barriers”  into  “Direct”  and  “Indirect”  has  been  done  in 
an  attempt  to  define  those  barriers  which  can  be  attacked  by  “direct”  action,  and  those 
barriers  which  will  only  yield  to  the  “indirect”  action  of  cultural  change. 

The  use  of  standards  has  always  been  and  will  continue  to  be  an  important  tool 
in  the  implementation  and  maintenance  of  discipline  throughout  Navy.  However,  it 
is  equally  true  that  adherence  to  “box  level”  standards  beyond  their  useful  life  is  a 
major  deterrent  to  progressive  change.  The  computing  capability  explosion,  which 
has  occurred  as  a  result  of  the  rapidly  advancing  technology  in  the  semiconductor 
industry  and  is  currently  being  fueled  by  unprecedented  national  commercial 
progress  in  software  tool  and  application  development,  must  find  its  way  into  Navy  C3 
and  combat  systems  as  soon  as  possible. 

For  Navy  to  enjoy  the  capability  explosion  and  its  associated  time  and  cost 
savings,  the  “Direct  Barriers”  must  be  clearly  identified  and  removed,  allowing  in  turn 
the  required  changes  in  the  “Indirect  Barriers.” 

The  functional  capability  of  our  hardware  is  increasing  while  the  size  is 
decreasing.  While  attaining  increased  functionality,  systems  become  grey  boxes,  grey 
boxes  become  modules,  and  modules  become  components.  It  is  clear  that  the 
functional  level  at  which  standards  are  imposed  must  not  remain  static.  These 
standards  must  reside  throughout  the  system,  down  to  the  component. 
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Recommendations  for  the  removal  of  the  direct  barriers  identified  here  will  lead 
to  the  cultural  change  required  for  obtaining  and  maintaining  effective  computing 
power  and  communication  in  the  U.S.  Navy. 

Although  DoD  and  Navy  policy  papers  have  been  issued  to  encourage  the  use 
of  COTS  hardware  and  software,  they  are  in  addition  to  existing  policy  that  requires 
MILSPEC  hardware  and  software.  Waivers  apparently  are  attainable,  but  not  without 
the  effort  required  to  staff,  process,  and  track  those  waiver  requests.  With  no  current 
advocate  for  COTS  and  the  conflicts  of  policy  for  COTS  and  MILSPECS,  most  program 
managers  will  follow  conventional  wisdom  and  build  with  MILSPEC  equipment. 
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POLICY  BARRIERS  (Cont.  2) 


BARRIERS  TO  COTS 


Indirect  Policy  Barriers 

•  Procurement  cycle  geared  to  "military  life 
cycles" 

-  Budgeting  through  logistics  cycle 

-  Second  source  and  data  rights 

•  Historical  Barriers 

-  System  definition,  including  space,  power  and 
cooling,  are  required  at  program  inception 


-  Functional  survivability  was  specified  for  existing 
battle  environments 


Further  aggravating  this  condition  are  the  indirect  barriers.  The  current 
procurement  process,  including  the  entire  Planning,  Programming  Budgeting  System 
(PPBS)  cycle,  is  geared  to  long  turnkey  program  developments.  Many  of  these 
activities,  including  shipbuilding,  require  long  lead  time  on  deliveries  of  computer 
systems  or  specific  installation  designs  to  accommodate  the  contracting  process.  A 
memorandum  of  agreement  between  OP-094  and  Naval  Sea  Systems  Command 
(NAVSEA)  regarding  the  LX  ship  design,  is  a  positive  effort  to  divorce  C4  systems 
identification  from  this  long  lead  time  process. 

Data  rights  are  another  long-standing  barrier  to  COTS  systems.  By  planning 
to  buy  and  not  upgrade  equipments  for  lifetimes  longer  than  the  commercial  market, 
the  data  rights  issue  often  forces  Navy  systems  away  from  commercial  systems. 
Innovative  contracting  practices  have  merged  recently  in  procurements  like  the 
Tactical  Computer-3  (TAC-3)  computer  buy  that  mitigate  data  rights  issues.  InTAC-3, 
winning  contractors  agree  to  provide  data  rights  if  they  stop  production  and  support 
of  the  equipment  that  is  still  in  Navy  operation.  In  commercial  industry,  second  tier 
manufactures  often  provide  replacement  parts  for  equipment  no  longer  supported  by 
the  original  vendor. 

Perhaps  the  biggest  barrier  is  the  historical  argument  that  MILSPEC  is  required 
to  survive  the  military  environment.  While  the  Panel  readily  agrees  that  most  COTS 
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equipment  will  not  pass  the  full  set  of  MIL  1 6400  environmental  tests,  we  question  the 
validity  of  these  requirements  in  today’s  combat  environment.  When  these  tests  were 
devised,  ships  were  largely  assemblies  of  stand  alone,  non-integrated  combat  systems 
subject  to  the  shock,  vibration,  temperature,  and  humidity  extremes  that  war 
represents.  Early  ships  and  aircraft  were  often  subjected  to  many  weapon  hits  before 
being  put  completely  out  of  action. 

Today’s  ships  and  aircraft  are  highly  integrated  combat  systems.  Each  of  the 
systems  are  interdependent  on  power,  cooling,  water,  and  information  flow.  When  hit 
by  modern  lethal  weapons,  it  is  difficult  for  these  platforms  to  continue  mission 
operation  even  though  they  are  mobile  and  provide  full  crew  support.  In  each  case 
investigated  by  the  Panel,  COTS  equipment  on  ships  that  were  damaged  by  weapons 
either  survived  as  well  as  MILSPEC  equipment  or  it  didn’t  matter  because  the  platform 
was  put  out  of  action.  This  would  indicate  that  combat  is  not  stressing  equipment  to 
the  level  of  MILSPEC  requirements.  Considering  the  tightly  coupled  integration  of 
modern  platforms,  it  is  difficult  to  label  MILSPEC  requirements  as  the  governing 
system  survivability  factor. 
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CULTURAL  BARRIERS 


BARRIERS  TO  COTS 


More  work,  more  professional  risk 
Obsolete  assumptions  and  analogies 
Business  as  usual  behind  facades 
Inadequate  understanding 
Myopic  views  about  competition 
Concern  about  reducing  mission  capability 
Concern  about  industry  direction 
Vendor  lobbying 


All  managers  have  too  much  to  do,  too  little  time,  and  too  many  difficult  choices. 
Accordingly,  buying  COTS  is  discouraged  whenever  it  requires  a  lengthy,  time- 
consuming  waiver  process.  In  one  extreme  case,  the  lack  of  an  easy  path  toward  COTS 
was  brought  home  to  us  when  one  briefer  said  explicitly  he  was  happy  that  a  Navy 
standard  computer  was  mandated  for  his  program  because  that  way  he  “didn’t  have 
to  think  about  what  to  use.”  Also,  waivers,  like  other  exceptions,  promote  a  sense  of 
increased  vulnerability  to  criticism  in  the  event  something  does  not  work  out  well. 
Program  managers  avoid  risk  by  staying  away  from  choices  that  look  like  lightning 
rods  for  blame. 

Over  and  over  again  the  Panel  heard  people  say  “It  (software)  costs  x  dollars; 
there  is  no  way  we  are  going  to  be  able  to  afford  to  rewrite  all  that.”  This  is  a  natural 
argument;  one  that  used  to  be  correct.  At  one  time,  the  cost  of  the  “installed  base” 
really  was  a  barrier  to  the  introduction  of  new  capabilities:  However,  modern  software 
realities  have  changed  the  picture  entirely,  especially  in  light  of  the  fact  that  many 
large  Navy  software  systems  consist  largely  of  operating  system  modules,  database 
manipulation  systems,  and  display  drivers.  Today,  such  systems  are  created 
commercially  by  assembling  reusable  COTS  components,  not  by  writing  from  scratch. 
The  fast  way  to  increased  capability  is  no  longer  to  build  expensively  on  a  base  of  old, 
obsolescent  code,  but  to  build  efficiently  with  high  productivity  on  an  inexpensive 
COTS  base. 


It  is  easy  to  sprinkle  a  little  OSA  and  COTS  over  a  development  program  and 
claim  that  the  program  is  resonant  with  the  thrust  of  the  OSA  and  COTS  movements. 
In  fact,  many  such  program  are  still  riddled,  on  all  levels,  with  Navy  unique  hardware 
and  software.  On  the  software  side  especially,  there  is  a  general  failure  to  realize  that 
the  benefits  of  COTS  are  easy  to  lose,  especially  when  fooling  with  operating  system 
software.  What  appears  to  be  a  small,  Navy  unique  change  deep  in  a  protocol 
hierarchy  may  greatly  limit  the  use  of  powerful  COTS  software  elsewhere.  Moreover, 
within  every  other  layer  and  module  the  small  change  touches  will  have  to  be 
maintained  expensively  by  Navy  instead  of  at  little  or  no  cost  by  COTS  vendors. 
Ideally,  Navy  specific  software  should  be  limited  to  the  application  layer,  and  much 
of  the  software  even  at  that  level  is  likely  to  benefit  from  COTS.  Thus,  we  conclude 
that  there  is  a  need  for  a  mechanism  that  ensures  the  beneficial  use  of  COTS,  not  just 
the  appearance  of  COTS  enthusiasm.  Furthermore,  we  conclude  that  there  is  a  need 
to  educate  program  managers  about  COTS  benefits,  so  these  benefits  are  not  lost 
inadvertently. 

There  is  a  general  assumption  that  second  sourcing,  with  all  the  corollary  data 
rights  and  source  code  requirements,  is  the  only  way  to  achieve  competition. 
Historically,  this  was  true,  but  that  was  before  revolutionary  growth  in  the  commercial 
market  for  computer  hardware  and  software.  Now,  ordinary  commercial  pressures, 
coupled  with  the  march  of  technology,  has  turned  high  performance  computers  into 
commodity  items.  Similarly,  the  development  of  reusable  software  as  a  base  has 
moved  software  away  from  a  develop-from-scratch  process  toward  a  module-assem¬ 
bly  process.  Accordingly,  the  cost  of  COTS  hardware  and  software  is  a  tiny  fraction 
of  Navy  specific  hardware.  Computer  hardware  and  software  companies  are  under 
increasing  and  irresistible  pressure  to  provide  long-term  support  and  acceptable 
upgrade  paths  for  their  products,  protecting  their  customers’  large  hardware  and 
software  capital  investments.  The  commercial  pressures  that  have  caused  a  rush 
toward  OSA  are  the  same  pressures  that  ensure  long  product  lifetimes.  Religious 
adherence  to  well-intended  second-sourcing  practices  that  exclude  the  use  of  COTS 
hardware  and  software  defeat  the  very  cost-saving  goals  from  which  those  practices 
were  derived. 

Many  people  are  too  quick  to  suppose  that  computers  are  failure-prone  devices 
that  are  hard  to  keep  in  the  logistics  system  for  the  traditional  thirty  years,  but  today, 
computers,  relative  to  other  electronic  equipment,  are  not  failure-prone  at  all. 
Thinking  about  how  to  keep  a  computer  in  service  for  thirty  years  is  inconsistent  with 
a  world  in  which  it  is  hard  to  find  a  thirty -year  old  computer  outside  of  a  museum,  or 
perhaps  a  Navy  ship. 

MILSPEC  standards  for  computers  should  be  set  such  that  the  ability  of  the  ship 
to  carry  out  its  mission  and  survive  should  not  be  compromised  by  those  computers. 
All  the  evidence  we  saw  indicates  that  COTS  hardware,  certainly  that  at  the  ruggedized 
and  militarized  end  of  the  robustness  spectrum,  has  not  reduced  any  ship’s  ability  to 
carry  out  its  mission  or  to  survive. 

Some  briefers  expressed  concern  that  vendors  might  choose  to  reverse  their 
movement  toward  OSA.  We  firmly  believe  there  is  no  going  back.  Now  that  customers 
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have  OSA,  they  are  demanding  OSA,  and  no  vendor  can  ignore  that  demand  and 
survive.  Other  briefers  expressed  concern  that  movement  to  COTS  might  soon  lead 
to  a  dependence  on  foreign  suppliers.  We  believe  this  is  a  “red  herring”  for  regulations 
can  be  written  to  guide  purchase  toward,  or  limit  purchases  to,  equipment  substan¬ 
tially  made  in  the  USA  or  its  close  allies. 

A  major  barrier  that  is  hard  to  control  is  vendor  lobbying.  COTS  manufacturers 
are  not  likely  to  lobby  for  military  sales  because  it  represents  such  a  small  fraction  of 
total  sales.  MILSPEC  equipment  vendors,  interested  in  holding  on  to  their  military 
unique  market,  will  continue  to  lobby.  This  may  result  in  Congressional  language  that 
must  be  changed  or  adhered  to. 
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TECHNICAL  BARRIERS 


BARRIERS  TO  COTS 


None  Identified  In  Industry 

•  Commercial  vendors  working  multi-level  security 

•  Computer  speeds  capable  of  meeting  real-time 
response  requirements 

•  Available  technology  for  afloat  high  bandwidth 

-  Antenna  space 

-  Frequency  allocation 

-  Assured  connectivity 


The  two  technical  issues  most  often  raised  by  COTS  skeptics  and  opponents  are 
the  security  issue  and  the  real-time  issue.  Both  issues  are  important,  but  the  Panel 
could  not  see  any  clear  reason  why  MILSPEC  would  be  inherently  superior  to  COTS 
with  respect  to  either  issue.  Quite  to  the  contrary,  COTS  seems  as  good  as  or  superior 
to  MILSPEC  in  actual  practice. 

For  applications  requiring  multi-level  security,  the  Panel  noted  several  COTS 
operating  systems  with  B2  security  ratings.  Not  only  is  this  superior  to  that  of 
MILSPEC  systems  operating  in  the  Fleet  today,  but  these  systems  were  developed  as 
much  for  the  commercial  market  as  the  military. 

For  applications  requiring  millisecond  response  time,  the  tendency  today, 
sensibly,  is  to  push  the  computing  out  into  the  weapon  itself.  This  movement  is  not 
outside  the  scope  of  our  recommendations.  For  combat  direction  systems,  like  ACDS, 
or  weapons ,  a  fast  COTS  machine  with  COTS  software  offers  response  times  that  are 
at  least  as  good  as  MILSPEC  machines  with  MILSPEC  software.  The  Panel  learned, 
for  example,  that  the  response  of  the  Joint  Operational  Tactical  System  II  (JOTS  II) 
was  as  good  or  better  than  the  response  of  the  MILSPEC  combat  direction  system  in 
the  same  room  when  provided  with  equal  access  to  incoming  information. 

Other  issues  that  were  introduced  by  skeptics  and  opponents  of  COTS  as 
“technical”  barriers  seemed  to  be  mainly  cultural  and/or  educational  in  nature. 
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Accordingly,  the  Panel  believes  there  are  no  significant,  strictly  technical,  barriers  to 
COTS  software  or  hardware. 
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X.  RECOMMENDATIONS 
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INCREASE  BANDWIDTH 


RE  COMMENDA  TIONS 


Immediately  increase  Navy  OTH  communications  (afloat, 
air,  ground)  using  commercial  satellites  and  COTS 
communications  equipment  to  support: 

•  Record  and  administrative  traffic 

•  Logistics  support 

•  Mission  planning  support 

•  Imagery  dissemination 

•  Tactical  data 


The  primary  limitation  to  effective  C3  among  naval  forces,  evident  in  Desert 
Storm,  and  I&W  and  queing  into  combat  systems,  is  the  availability  of  bandwidth  for 
day-to-day  operations. 

Preliminary  investigation  and  interviews  indicate  commercial  satellite  capabili¬ 
ties  are  sufficient  to  meet  most  deficient  bandwidth  requests.  The  daily  ATO  took  up 
to  six  hours  of  system  time  to  transmit  and  print  in  Navy  and  afloat  Marine  commands. 
Secondary  (only)  imagery  was  not  available  at  key  commands  except  by  manual 
distribution,  often  arriving  later  than  tactically  required. 

The  most  immediate  recommendation  of  this  study  is  to  appoint  a  key  leader 
to  plan  and  implement  a  commercial  satellite  solution  to  augment  Navy  and  Marine 
communications  afloat,  in  the  air,  and  on  the  ground.  Special  attention  must  be  given 
to  OTH  amphibious  landing  requirements. 

Standards  and  protocols  to  allow  Navy-Navy,  Navy-Service  and  Navy-Industry 
to  communicate  via  voice  and  data  are  imperative. 

The  Panel  recommends  an  analysis  be  done  to  determine  which  commercial 
standards  and  technology  should  be  adopted  for  naval  communications.  This  should 
include,  but  not  be  limited  to,  theater-level  communications  required  for  record  and 
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administrative  tasking,  logistics  coordination,  mission  planning,  support,  and  imag¬ 
ery  dissemination. 

In  summary,  a  much  broader  use  of  COTS  communications  systems  should  be 
employed  to  augment  current  Navy  communications.  The  requirement  is  here  today 
as  demonstrated  in  the  extensive  use  of  TLAM  targeting  data.  Access  to  higher 
resolution  images  in  larger  quantities,  requiring  bandwidth  on  the  order  of  100  times 
greater  than  is  currently  available,  will  become  critical  to  the  success  of  future  Navy 
operations. 
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INVERT  WAIVER  PROCESS 


RE  COMMEND  A  TIONS 


Require  an  Acquisition  Executive  waiver  for  MILSPEC 
computer  and  communication  equipment: 

•  Use  COTS  or  ruggedized  COTS 

-  Cancel  the  current  TADSTANDs  and 
OPNAVINST  5200.28 

•  Eliminate  Ada  exemption  requirement  for 
COTS 

-  Ada  can  be  used  as  a  binder  language 


The  use  of  OSA  COTS  should  be  encouraged  for  all  combat  and  non-combat 
Navy  computer  and  communication  hardware  and  software. 

All  program  managers  should  be  required  to  use  COTS  in  embedded  or 
subsystem  configurations  unless  a  waiver  is  granted  by  the  Acquisition  Executive. 
Our  findings  indicate  that  on  average,  75%  cost  reduction  and  60-80%  schedule 
improvement  can  be  experienced  through  the  use  of  COTS  with  no  impact  on  mission 
achievement.  In  some  cases,  ruggedized  COTS  may  be  required  to  meet  certain 
environmental  requirements.  Ruggedized  COTS  should  be  treated  as  COTS  and 
should  not  require  a  waiver  if  all  OSA  standards  are  met. 

The  Ada  language  waiver  process  should  be  modified  to  allow  OSA/COTS 
operating  systems,  database  software,  display  graphics  and  application  software  to 
be  used  for  any  mission  critical  or  non-mission  critical  system.  An  Ada  waiver  should 
be  required  only  if  new  code  must  be  developed  and  this  code  is  not  planned  to  be 
implemented  in  Ada. 

Any  requests  for  a  waiver  shall  include  a  complete  cost  benefit  analysis.  In 
addition,  any  request  based  on  the  cost  of  replacing  existing  Navy  software  or 
hardware  shall  include  a  complete  analysis  of  the  net  cost  of  replacing  that  existing 
software  or  hardware  with  COTS.  This  analysis  will  include  a  thorough  examination 
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of  the  impact  each  MILSPEC  choice  will  have  on  the  use  of  COTS  in  other  related 
systems. 

Whenever  a  waiver  request  argues  that  COTS  software  is  not  available  to  replace 
existing  software,  forcing  the  rewriting  of  software,  the  waiver  request  shall  include 
a  description  of  the  efforts  made  to  identify  suitable  COTS  software  and  the  reasons 
why  COTS  alternatives  are  not  acceptable. 
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EDUCATE  PROGRAM  MANAGERS 


RE  COMMENDA  TIONS 


Educate  program  managers  on  the  value  of 
"Open  Systems  Architecture  /  COTS" 

•  Install  an  "Open  Systems  Architecture  /  COTS" 
curriculum  into  Defense  Systems  Management 
College  (DSMC) 


Because  OSA/COTS  technology  potentially  permeates  a  large  portion  of  Navy 
structure,  policy  changes,  unless  coupled  with  education,  will  provide  only  marginal 
return.  We  believe  that  program  managers,  engineers,  and  logisticians,  should  be 
educated  on  the  technology  of  OSA  and  the  potential  benefits  of  leveraging  industry 
development  in  support  of  military  systems.  The  Defense  Systems  Management 
College  (DSMC),  the  mandated  training  course  for  all  DoD  program  managers, 
provides  a  unique  opportunity  to  expose  emerging  program  managers  to  the  value  of 
participating  with  industry  in  the  “Open  System”  revolution. 
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ESTABLISH  ACCOUNTABILITY 


RECOMMENDA  TIONS 


Recognizing  That ... 

•  Migration  to  COTS  and  OSA  systems  is 
important;  and 

•  Policy  and  cultural  barriers  exist 
The  Acquisition  Executive  should  ... 

•  Require  semiannual  reporting  from  Program 
Executive  Officers  (PEOs),  Direct  Reporting 
Program  Managers  (DRPMs),  &  System 
Commands  (SYSCOMs)  to  include: 

-  Report  relative  changes  in  the  balance 


between  COTS  and  MILSPEC  systems 


Overcoming  difficult  obstacles  requires  the  attention  of  senior  management 
and  a  mechanism  for  measuring  progress.  The  Panel  believes  tracking  the  changes 
between  the  status  of  COTS  and  MILSPEC  systems  on  a  semi-annual  basis  will  serve 
that  purpose.  This  level  of  accountability  would  also  aid  the  education  problem  by 
raising  the  awareness  of  this  technology. 
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XI.  APPENDIX  A  -  GLOSSARY  OF  TERMS 


ACDS  -  Advanced  Combat  Direction  Systems 

ADM  -  Advanced  Development  Model 

ADP  -  Automated  Data  Processing 

APEX  -  ASW  Prototype  Experimentation 

ARPA  -  Advanced  Research  Projects  Agency 

ARPANET  -  Advanced  Research  Projects  Agency  Network 

ASO  -  Aviation  Supply  Office 

ASN  (RD&A)  -  Assistant  Secretary  of  the  Navy  (Research,  Development,  and  Acquisi¬ 
tion) 

ASW  -  Anti-Submarine  Warfare 

ASWOC  -  Anti-Submarine  Warfare  Operations  Center 
ATO  -  Air  Tasking  Order 
BG  -  Battle  Group 
BPS  -  Bits  Per  Second 

C3  -  Command,  Control,  and  Communications 

C3I  -  Command,  Control,  Communications  and  Intelligence 

C4I  -  Command,  Control,  Communications,  Computers  and  Intelligence 

CAMS  -  Naval  Communications  Area  Master  Station 

CDS  -  Combat  Direction  Systems 

CENTCOM  -  U.S.  Central  Command 

CNA  -  Center  for  Naval  Analyses 

COE  -  Common  Operating  Environment 

COMUSNAVCENT  -  Commander,  U.S.  Naval  Central  Command 
COTS  -  (HW /  SW)  -  Commercial  Off  the  Shelf  (Hardware /  Software) 

CSS  -  Communications  Support  System 
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CUDIXS  -  Common  User  Data  Information  Exchange  System 

CV  -  Fixed  Wing  Aircraft  Carrier 

DAMA  -  Demand  Assigned  Multiple  Access 

DARPA  -  Defense  Advanced  Research  Projects  Agency 

DBS  -  Direct  Broadcast  Satellites 

DoD  -  Department  of  Defense 

DRPM  -  Direct  Reporting  Program  Manager 

DSCS  -  Defense  Satellite  Communications  System 

DSMC  -  Defense  Systems  Management  College 

EW  -  Electronic  Warfare 

FIST  -  Fleet  Imagery  Support  Terminal 

FLT  BCST  -  Fleet  Broadcast 

GMF  -  Ground  Mobile  Facility 

HF  -  High  Frequency 

HMMV  -  High  Mobility  Multipurpose  Vehicle 
Hz  -  Hertz 

I&W  -  Indications  and  Warning 

INMARSAT  -  International  Maritime  Satellite 

INTELSAT  -  Intelligence  Satellite 

ISDN  -  Integrated  Services  Data  Network 

ISO  -  International  Standards  Organization 

JFACC  -  Joint  Forces  Air  Component  Commander 

JOTS  II  -  Joint  Operational  Tactical  System  II 

LAN  -  Local  Area  Network 

MACSAT  -  Multiple  Access  Satellite 

MAGTF  -  Marine  Air  Ground  Task  Force 
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MBYTES  -  Megabytes 

MEB  -  Marine  Expeditionary  Battalion 

MEF  -  Marine  Expeditionary  Force 

MFLOPS  -  Million  Floating  Points  of  Operations  per  Second 
MIF  -  Maritime  Interdiction  Force 
MIL  -  Military 

MILSPEC  -  Military  Specification 
MIPS  -  Million  Instructions  Per  Second 
MOCC  -  Mobile  Operations  Control  Center 
MPA  -  Maritime  Patrol  Aircraft 

NAVCENT  RIYADH  -  Naval  Central  Command  Riyadh 

NAVSEA  -  Naval  Sea  Systems  Command 

NCA  -  National  Command  Authority 

NOSC  -  Naval  Ocean  Systems  Center 

NTCS-A  -  Navy  Tactical  Command  System  -  Afloat 

OP-094  -  Director,  Space  and  Electronic  Warfare 

OPNAVINST  -  OPNAV  Instruction 

OSA  -  Open  Systems  Architecture 

OSI  -  Open  Systems  Interconnect 

OSS  -  Operations  Support  System 

OTCIXS  -  Officer  in  Tactical  Command  Information  Exchange  Service 

OTH  -  Over  The  Horizon 

PC  -  Personal  Computer 

PEO  -  Program  Executive  Officer 

PPBS  -  Planning,  Programming  Budgeting  System 

RAM  -  Random  Access  Memory 
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SATCOM  -  Satellite  Communications 


SHF  -  Super  High  Frequency 

SPAWAR  -  Space  and  Naval  Warfare  Systems  Command 

SQL  -  Standard  Query  Language 

STRAP  -  Sonobuoy  Thinned  Random  Array  Program 

STU-  Secure  Telephone  Unit 

S/W  -  Software 

SYSCOM  -  Systems  Command 

TAC-3  -  Tactical  Computer  3 

TACINTEL  -  Tactical  Intelligence  Information  Exchange  Subsystem 
TADIXS  -  Tactical  Data  Information  Exchange  System 
TADSTANDS  -  Tactical  Digital  Standards 

TCP/IP  -  Transmission  Control  Protocol  and  Internet  Protocol 

TLAM  -  Tomahawk  Land  Attack  Missile 

TOR  -  Terms  of  Reference 

TQM  -  Total  Quality  Management 

UHF  -  Ultra  High  Frequency 

USN  -  U.S.  Navy 

VHF  -  Very  High  Frequency 

VME  -  Virtual  Machine  European 

WAN  -  Wide  Area  Network 
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XII.  APPENDIX  B  -  PRESENTATIONS  /  BRIEFINGS 

The  Panel  met  for  three,  two-day  sessions  prior  to  the  two  week  Summer  Study 
session.  Briefings  received  during  these  four  sessions  were  from: 

Government 


Space  and  Electronic  Warfare  (OP-094) 

-  OP-094B,  Deputy  Director 

-  OP-94 1E6  (ADP  Security  Requirements),  94 1G  (Voice/ Data  Networks),  94 1H 
(Strategic  C3) 

-  OP-942F  (C2  Systems  Branch),  942F4  (NTCS-A,  Common  Operating  Envi¬ 
ronment,  Fleet  Imagery  Requirements),  942 F8  (Copernicus  Architecture) 

-  OP-943C  (SATCOM  Requirements  Branch) 

Navy  Computers  and  Telecommunications  Command  (NCTC)  (Special  Assistant  to 
CNTC  for  Mergers  and  Consolidations) 

Office  of  the  Director,  Information  Systems  for  Command,  Control,  Communications 
and  Computers  (ODISC4) 

Information  Technology  Acquisition  (ITAC)  (Navy  Ada  Implementation  Team) 

Defense  Communications  Agency  (DCA) 

-  Defense  Information  System  Network  (DISN)  Branch 

-  DCA  Technical  Advisor 

Chief,  Defense  Information  System/ WWMCCS  ADP  Modernization 
Naval  Research  Laboratory 

Superintendent,  Information  Technology  Division 
Naval  Ocean  Systems  Center 

-  Advanced  Combat  Direction  System  Project 

-  Consolidated  System  Support  Project 

-  Navy  Tactical  Command  System  -  Afloat  Project 

-  Copernicus  Architecture  Project 

Center  for  Naval  Analyses 

-  Study  Director  Alternative  Logistics  Concepts  for  COTS 

-  Study  Director  SEW /  C3I  Desert  Storm  Lessons  Learned 

1st  Marine  Expeditionary  Force 

-  Director  G-6 

5th  Marine  Expeditionary  Battalion 

-  Operations  Officer 

9th  Communications  Battalion 

-  Communications  Officer 
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COMPHIBGRU  3 


Operations  Officer 

Space  and  Naval  Warfare  Systems  Command  (SPAWAR) 

-  SPAWAR  3 1  (ASW  C3I) 

-  SPAWAR  324  (NGCR  Division  Director,  Head  Supervisor) 

SPAWAR  324 1  (Ada  Program  Office) 

Naval  Sea  Systems  Command  (NAVSEA) 

-  NAVSEA  06K  (MILSTD  2036  Project  Director) 

-  NAVSEA  06KC  (Combat  System  Engineer  for  LHD-1) 

-  NAVSEA  PMS-377  (OTHACCS  Program  Officer) 

-  NAVSEA  PMS-4 12  (Director) 

-  NAVSEA  PMS-400  (USS  Princeton  Shock  Assessment) 

Industry 

Mitre  Corporation 

-  Directing  Engineer  ISDN 

-  Program  Manager  ISDN 

-  Technical  Staff  -  Interoperable  C3  Reports 

-  Senior  Vice  President  -  Desert  Storm  Lessons  Learned 

Corporation  for  Open  Systems 

-  Director  Business  Strategy 
Digital  Equipment  Corporation 

-  Strategic  Account  Manager  USN  C3I 
Microsoft  Corporation 

Senior  Technical  Consultant,  Gov’t  National  Account  Executive 
Hughes  Aircraft,  El  Segundo,  CA 

-  DBS  Network  Systems 

Demonstrations  /  Tours 

During  the  summer  session,  the  Panel  received  three  briefings  and  demonstrations / 
tours  of  programs  ongoing  at  NOSC;  CSS,  ACDS  and  NTCS-A.  The  Panel  also  visited 
the  USS  Ranger  (CV-61). 
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